Sistema experto basado en reglas para la documentación de requerimientos de Software (página 2)
9.2.2 DIMENSIONES DE LA INGENIERÍA DE
REQUERIMIENTOS
Una posible visión de la ingeniería de requerimientos es
considerarla como un proceso de
construcción de una especificación
de requerimientos en el que se avanza desde especificaciones
iniciales, que no poseen las propiedades oportunas, hasta
especificaciones finales completas, formales y acordadas entre
todos los participantes, (ver figura 5) [POH 1994].
Figura 5. Dimensiones de la
Ingeniería de Requerimientos
Fuente: Informática Gestión
– Sistemas
Por un lado están los factores
psicológicos y cognitivos que afectan al grado de
constitución del conocimiento
sobre el sistema que se
desea desarrollar, es decir, el llegar a conocer la totalidad de
los requerimientos que debe satisfacer el sistema.
Por otro lado, está el grado de formalismo
de la representación del conocimiento sobre dichos
requerimientos, teniendo en cuenta que un mayor grado de
formalismo no implica necesariamente un mayor conocimiento [POH,
1997].
Por último, como ya se comentó
anteriormente, están los aspectos sociales, ya que al ser
un proceso en el que participan personas con diferentes puntos de
vista, es necesario llegar a un punto de acuerdo,
normalmente mediante algún tipo de
negociación [BOE, 1994].
Estos factores pueden representarse como tres
dimensiones [POH, 1994], de forma que durante el proceso de
ingeniería de requerimientos se avanza desde
especificaciones incompletas, informales e individuales hacia la
especificación ideal que sería completa, formal y
acordada entre todos los participantes.
Como complemento a este modelo, se
afirma que las actividades del proceso de ingeniería de
requerimientos serían los vectores que hacen
avanzar las especificaciones hacia su situación
ideal.
Así, las actividades de elicitación
harían avanzar el proceso en las dimensiones de constitución y acuerdo, las actividades de
análisis lo harían en
constitución y formalidad y las actividades de
validación.
9.2.3 CONCEPTO DE
REQUERIMIENTO
Una de las características de la IR es la falta
de uniformidad en la terminología empleada, tanto para los
conceptos básicos como para los procesos y los
productos
[DAV, 1993], [BRA, 1990], [POH, 1997]. Uno de los conceptos
afectados por dicha falta de uniformidad es el de
requerimiento.
La definición que aparece en [IEEE, 1990] es la
siguiente:
Requerimiento (1):
(a) una condición o capacidad
que un usuario necesita para resolver un problema o lograr un
objetivo.
(b) una condición o capacidad que debe
tener un sistema o un componente de un sistema para satisfacer un
contrato, una
norma, una especificación u otro documento
formal.
(c) una representación en forma de
documento de una condición o capacidad como las expresadas
en (a) o en (b).
Mientras que la que aparece en [DOD, 1994] es más
concisa:
Requerimiento (2): característica del
sistema que es una condición para su
aceptación.
Otra posible definición es la siguiente [GOG,
1994]:
Requerimiento (3): propiedad que un sistema
debería tener para tener éxito
en el entorno en el que se usará.
Sin embargo, a pesar de esta aparente simplicidad del
concepto, es frecuente encontrar el término requerimiento
calificado con adjetivos que pueden resultar confusos en un
primer momento: de sistema, hardware, software, de usuario,
de cliente,
funcional, no funcional, etc.
9.2.4 DIMENSIONES DE LOS
REQUERIMIENTOS
La gran cantidad de calificativos que se aplican al
término requerimiento muestran distintos aspectos
ortogonales que ha menudo se consideran aisladamente.
Para intentar clarificar la situación, se puede
identificar tres dimensiones en las que se pueden clasificar los
requerimientos, (ver figura 6). Estas tres dimensiones
son:
- Ámbito: esta dimensión indica en
qué ámbito se debe entender el requerimiento. En
general, y siguiendo entre otras las propuestas de [IEEE,
1997], [DOD, 1994] y [DAV, 1993], un ámbito de
sistema indica que el requerimiento debe cumplirse a
nivel de sistema, entendiendo por sistema un conjunto de
hardware y software.
Figura 6. Dimensiones de los
Requerimientos
Fuente: Informática Gestión
– Sistemas
Si el ámbito es de software quiere decir
que el requerimiento sólo afecta a la parte software de un
sistema, mientras que si es el ámbito es de
hardware sólo afecta a la parte
hardware.
Para entender esta clasificación conviene
recordar que [DOD, 1994] es una norma militar y que las normas [IEEE,
1997] están fuertemente influidas por dichas normas
militares. En el contexto de los desarrollos para fines militares
es frecuente tener que desarrollar sistemas en los
que el hardware juega un papel tan importante como el
software.
La concepción de sistema como conjunto, hardware
y software, no es la única. Por ejemplo, en Métrica
V2.1 [MAP, 1995] se denominan requerimientos del sistema a los
requerimientos que ha de cumplir el sistema a desarrollar,
entendiendo por sistema el conjunto de procesos tanto
automáticos como manuales. En esta
situación se pueden encontrar matices que indiquen si un
requerimiento se refiere al sistema en su conjunto o sólo
al software, aunque en general dichas diferencias se obvian y no
se diferencia entre los distintos ámbitos.
Las dimensiones se describen a
continuación:
– Característica que define: esta
dimensión clasifica los requerimientos en función de
la naturaleza de
la característica del sistema deseada que se especifica.
La clasificación más habitual suele ser la de
requerimientos funcionales (qué funciones debe
realizar el sistema) y no funcionales (otras
características del sistema).
En [POH,1997] aparece una completa clasificación
denominada RSM (Requirements Specification Model, Modelo
de Especificación de Requerimientos), cuyas principales
clases son: requerimientos funcionales, requerimientos de
datos y
requerimientos no funcionales.
Siguiendo la clasificación RSM, es conveniente
separar de los requerimientos funcionales a los requerimientos de
datos o de almacenamiento de
información, que establecen qué
información debe almacenar el sistema por ser relevante
para las necesidades y objetivos de
clientes y
usuarios.
Es conveniente destacar que al grupo de
requerimientos no funcionales no se le ha prestado la atención suficiente y que ya hay opiniones
que lo consideran como heterogéneo donde se han
clasificado aquellos requerimientos que resultan
incómodos [BAS, 1998]. Un ejemplo de esta
situación es la escasa importancia que se les ha dado en
las técnicas
de modelado de sistemas, tanto estructuradas como orientadas a
objetos o formales.
– Audiencia: Esta dimensión
fundamental, indica la audiencia a la que está dirigido el
requerimiento, es decir, las personas que deben ser capaces de
entenderlo. En general, se pueden distinguir dos tipos de
audiencia, los clientes y usuarios, que no tienen
porqué tener formación en ingeniería del
software, y los desarrolladores de software.
Cuando la audiencia está formada por clientes y
usuarios, la forma más habitual de definir los
requerimientos es mediante lenguaje
natural.
En el caso de que la audiencia prevista esté
formada por desarrolladores de software, los requerimientos
suelen expresarse mediante un modelo, normalmente utilizando
técnicas estructuradas, orientadas a objetos o
formales.
Se usará como referencia la nomenclatura
propuesta en [ROM, 1990] y en [BRA, 1990] en la que se denominan
requerimientos orientados al cliente, abreviadamente
requerimientos–C, a los requerimientos desde el
punto de vista de los clientes y usuarios, y requerimientos
orientados al desarrollador, abreviadamente
requerimientos–D, a los requerimientos desde el
punto de vista de los desarrolladores.
No obstante, es relativamente frecuente encontrar el
término requerimiento de usuario o requerimiento
de cliente para designar requerimientos–C de sistema o
de software, y el término requerimiento software
para designar requerimientos–D de software, se usará
los dos tipos de requerimientos ya que están
relacionados.
Un ejemplo de este uso puede verse en las normas de
desarrollo de
software de la Agencia Espacial Europea [MAZ, 1994].
9.3 SISTEMAS
EXPERTOS
9.3.1 DEFINICIÓN DE SISTEMA
EXPERTO
La más poderosa contribución de los
sistemas expertos es poner al servicio de
los analistas noveles la experiencia adquirida por aquellas
personas consideradas verdaderos especialistas en el área.
[DAV, 1993]
Un SE, es un software que imita el comportamiento
de un experto humano en la solución de un problema. Pueden
almacenar conocimientos de expertos para un campo determinado y
solucionar un problema mediante deducción lógica
de conclusiones. [MED, 2004]
Programas que contienen tanto conocimiento declarativo
(hechos a cerca de objetos, eventos y/o
situaciones) como conocimiento de control
(información a cerca de los cursos de una acción), para emular el proceso de
razonamiento de los expertos humanos en un dominio en
particular y/o área de experiencia. [CAT, 1999]
Para el presente trabajo se
utilizará la siguiente definición: Software que
incorpora conocimiento de experto sobre un dominio de
aplicación dado, de manera que es capaz de resolver
problemas de
relativa dificultad y apoyar la toma de
decisiones inteligentes en base a un proceso de razonamiento
simbólico. [CAS, 2002]
9.3.2 COMPONENTES DE UN SISTEMA
EXPERTO
Una característica decisiva de los Sistemas
Expertos es la separación entre conocimiento (reglas,
hechos) por un lado y su procesamiento por el otro. A ello se
añade una interfaz de usuario y un componente explicativo,
(ver figura 7).
A continuación se muestra una breve
descripción de cada uno de los
componentes:
- La Base de Conocimientos de un Sistema Experto
contiene el
conocimiento de los hechos y de las experiencias de los
expertos en un dominio determinado. - El Mecanismo de Inferencia de un Sistema
Experto puede simular la estrategia de
solución de un experto. - El Componente Explicativo explica al usuario
la estrategia de solución encontrada y el porqué
de las decisiones tomadas. - La Interfaz de Usuario sirve para que
éste pueda realizar una consulta en un lenguaje lo
más natural posible. - El Componente de Adquisición ofrece
ayuda a la estructuración e implementación del
conocimiento en la base de conocimientos.
Figura 7. Componentes de un Sistema
Experto
Fuente: Sistemas Expertos: Aspectos
Técnicos http://ciberconta.es/selecciones/sistexpatll00.htm
9.3.3 TIPOS DE CONOCIMIENTO
Existen dos tipos:
- Conocimiento abstracto, es de validez general y se
almacena permanentemente. - Conocimiento concreto,
es de validez particular y se almacena temporalmente. Son los
datos o hechos de un problema especifico que es resuelto por
el Sistema Experto.
Para el presente trabajo se usará los dos tipos
de conocimiento. El primero, como se usará marcos de
problema elementales, serán de validez general los cuales
se almacenaran permanentemente y el tipo de conocimiento concreto
será empleado cuando se resuelva un problema en especifico
partiendo de lo general a lo particular.
9.3.4 FUENTES DE
CONOCIMIENTO
Existen dos tipos:
- Fuentes Primarias, acceso directo al conocimiento
(Experto Humano, libros,
textos, Internet). - Fuentes Secundarias, acceso indirecto a la
información (Referencias, Publicaciones). [MED,
2004]
Los cuales se emplearan en el desarrollo del presente
trabajo.
9.3.5 CLASIFICACION DE LOS SISTEMAS
EXPERTOS
Los sistemas expertos se clasifican de acuerdo al tipo
de conocimiento que se utiliza:
- Sistemas Expertos basado en reglas, la
construcción de la base de conocimiento es en base a
reglas, lo cual, en algunos casos se elabora sencillamente,
la explicación de las conclusiones es simple. El
motor de
inferencia se realiza con algoritmos
complejos, lo cual es relativamente lento, además que
el
aprendizaje estructural es complejo. - Sistemas Expertos basado en probabilidades,
la construcción de la base de conocimiento es en base
a frecuencias lo cual requiere de mucha información,
la explicación de las conclusiones resulta mas
compleja. El motor de inferencia se realiza con algoritmos
simples, el aprendizaje
parametrico es sencillo. [MED, 2004]
Se empleará el conocimiento basado en reglas
porque la información con que se cuenta es de tipo
determinístico, ya que se recabará datos
históricos, de proyectos que
fracasaron así como de los que lograron superar los
obstáculos en las etapas iniciales del desarrollo de
software, de las consultoras de software.
9.3.6 SISTEMAS EXPERTOS BASADOS EN
REGLAS
Los sistemas basados en reglas son los más
comúnmente utilizados. Su simplicidad y similitud con el
razonamiento humano, han contribuido para su popularidad en
diferentes dominios. Las reglas son un importante paradigma de
representación del conocimiento. [CAT, 1999]
Las reglas representan el conocimiento utilizando un
formato SI-ENTONCES (IF-THEN), es
decir tienen 2 partes:
- La parte SI (IF), es el
antecedente, premisa, condición o
situación. - La parte ENTONCES
(THEN), es el consecuente, conclusión,
acción o respuesta.
Las reglas pueden ser utilizadas para expresar un amplio
rango de asociaciones,
Una declaración de que algo es verdadero o es un
hecho conocido, es una afirmación. El conjunto de
afirmaciones se conoce frecuentemente con el nombre de base de
afirmaciones. De igual forma, al conjunto de reglas se lo
denomina base de reglas.
Un sistema basado en reglas utiliza el modus
ponens para manipular las afirmaciones y las reglas durante
el proceso de inferencia. Mediante técnicas de
búsqueda y procesos de unificación, los sistemas
basados en reglas automatizan sus métodos de
razonamiento y proporcionan una progresión lógica
desde los datos iniciales, hasta las conclusiones deseadas. Esta
progresión hace que se vayan conociendo nuevos hechos o
descubriendo nuevas afirmaciones, a medida que va guiando hacia
la solución del problema.
En consecuencia, el proceso de solución de un
problema en los sistemas basados en reglas va realizando una
serie de inferencias que crean un sendero entre la
definición del problema y su solución, es por estas
razones que utilizaremos el conocimiento basado en reglas para
nuestro objeto bajo estudio. Las inferencias están
concatenadas y se las realiza en forma progresiva, por lo que se
lo que se dice que el proceso de solución origina una
cadena de inferencias.[CAT, 1999]
9.4 METODOLOGIA DE WEISS Y KULIKOWSKI
Para el desarrollo de un sistema experto Weiss y
Kulikowski [WEI, 1984] sugieren las siguientes etapas para el
diseño
e implementación de un sistema experto, ver la figura
8.
- Planteamiento del problema. La primera etapa
en cualquier proyecto es
normalmente la definición del problema a resolver.
Puesto que el objetivo principal de un sistema experto es
responder a preguntas y resolver problemas, esta etapa es
quizás la más importante en el desarrollo de un
sistema experto. Si el sistema está mal definido, se
espera que el sistema suministre respuestas
erróneas. - Encontrar expertos humanos que puedan resolver el
problema. En algunos casos, sin embargo, las bases de datos
pueden jugar el papel del experto humano. - Diseño de un sistema experto. Esta
etapa incluye el diseño de estructuras
para almacenar el conocimiento, el motor de inferencia, el
subsistema de explicación, la interfaz de usuario,
etc. - Elección de la herramienta de
desarrollo. Debe decidirse si realizar un sistema experto a
medida utilizando lenguaje de
programación. - Desarrollo y prueba de un prototipo. Si el
prototipo no pasa las pruebas
requeridas, las etapas anteriores (con las modificaciones
apropiadas) deban ser repetidas hasta que se obtenga un
prototipo satisfactorio. - Refinamiento y generalización. En esta
etapa se corrigen los fallos y se incluyen nuevas posibilidades
no incorporadas en el diseño inicial.
Mantenimiento y puesta al día. En esta etapa el
usuario plantea problemas o defectos del prototipo, corrige
errores, actualiza el producto con
nuevos avances, etc.
Todas estas etapas influyen en la calidad del
sistema experto resultante, que siempre debe ser evaluado en
función de las aportaciones de los usuarios.
Figura 8. Etapas en el Desarrollo de un
Sistema Experto
Fuente: Sistemas Expertos y Modelos de
Redes
Probabilísticas
Enrique Castillo, José Manuel Gutiérrez, y Ah S.
Hadi. [CAT, 1999]
9.5 LENGUAJE DE
MODELADO UNIFICADO UML
El presente proyecto tomará en cuentan los
componente de un sistema experto desde el punto de vista de
UML.
9.5.1 REQUERIMIENTOS
Son una descripción de las necesidades o deseos
de un producto. Su objetivo es identificar y documentar lo que en
realidad se necesita, en forma que claramente se comunique al
cliente, estos deben ser definidos de manera inequívoca de
modo que se detecten los riesgos y no
se presenten sorpresas al momento de entregar el
producto.
Se recomienda los siguientes puntos:
- Panorama General: Se limita el campo de
acción. - Clientes: Se realiza una lista de los
involucrados. - Metas: Se lista los objetivos, estos deben limitarse
al panorama general. - Funciones del sistema: Hay que identificarlas y
listarías en grupos
cohesivos y lógicos. - Atributos del Sistema: Es el listado de
características o dimensiones, cabe mencionar que no son
funciones, pero pueden abarcar todas las funciones o ser
específicos de un función o grupo de
funciones.
9.5.2 CASOS DE USO
El caso de uso es una estructura
para describir la forma en que un sistema lucirá para los
usuarios potenciales, su elaboración se la realiza con la
colección de escenarios iniciadas por una entidad llamada
actor7, el resultado del caso de uso deberá
tener algún valor, ya sea
para el actor que lo inició o para otro, también es
posible volver a utilizar un caso de uso para ello existen dos
maneras. [LAR-99]
La primera es por "inclusión", la cual consiste
en utilizar los pasos de un caso de uso como parte de la
secuencia de pasos de otro caso de uso.
La segunda forma es por "extensión" el cual
consiste en crear un nuevo caso de uso mediante la adición
de pasos a un caso de uso existente.
Los casos de uso requieren tener al menos un
conocimiento parcial de los requerimientos del sistema, ellos
están contenidos en un documento narrativo que describe a
secuencia de eventos del actor (agente externo) que utiliza un
sistema para completar un proceso. UML incluye formalmente el
concepto de casos de uso y sus diagramas de uso,
a continuación su descripción:
(1) NOMBRE DEL CASO DE USO:
Los casos de uso son historias o casos de utilización de
un sistema; no son exactamente los requerimientos ni las
especificaciones funcionales, sino que ejemplifican e incluyen
tácitamente los requerimientos en las historias que
narran, su representación grafica se ubica en la Figura 9
(a).
(2) LOS ACTORES: Están representados por
el papel que desempeñan en el caso: una persona, un
componente de hardware u otro sistema. Conviene escribir su
nombre con mayúscula en la narrativa del caso para
facilitar la identificación, su representación
gráfica se ubica en la Figura 9 (b)
(3) LÍNEAS DE INTERCONEXIÓN:
Una línea asociativa conecta a un actor con el caso de uso
y representa la
comunicación entre el actor y el caso de uso. La
línea asociativa es sólida, corno a que conecta a
las clases asociadas, su representación grafica se ubica
en la Figura 9 (d).
(4) LOS SISTEMAS Y SUS
FRONTERAS: Un caso de uso describe la interacción con un "sistema". Las fronteras
ordinarias del sistema son: la frontera
hardware / software de un dispositivo o sistema de computo, el
departamento de una organización, la
organización entera. Es importante definir la frontera
del sistema para identificar lo que es interno o externo,
así como las responsabilidades del
sistema. El ambiente
externo está representado únicamente por actores, y
el interno por casos de uso, su representación grafica se
ubica en la Figura 9 (c).
[SCH-2000]
Ya elaborados los casos de uso no es necesario, pero
sirve de ayuda realizar un modelo conceptual, el cual se lo
representa por medio de diagramas de clases, este muestra
gráficamente (ver figura 10) un grupo de diagramas que
describen los conceptos, objetos, los atributos, acciones y las
asociaciones del dominio que se juzgan importantes.
Ya identificadas las clases de realiza la
descripción diagramas de secuencias, estos describen el
curso particular de los eventos de un caso de uso, los actores
internos que interactúan directamente con el sistema (como
caja negra), y con los eventos del sistema generados por los
actores. [LAR-99]
Con la información hasta ahora recolectada se
puede elaborar la base de conocimiento y la base de hechos, esto
gracias a la información que recabo los diagramas de
clases.
Ya expuesto los requerimientos y los casos de uso, se
ampliara como UML realiza el modelado de un sistema
experto.
Figura 9. Iconos Del Lenguaje UML Para La
Descripción De Procesos
Fuente: UML Y Patrones Introduccion Al
Analisis Y Diseño Orientado A Objetos De Craig
Larman
Figura 10. Representación De Los
Diagramas De Clase
Fuente: Fuente: UML Y Patrones
Introduccion Al Analisis Y Diseño Orientado A Objetos De
Craig Larman
9.5.3 BASE DE CONOCIMIENTO
No es el único componente de un sistema experto.
Si lo fuera un sistema experto podría ser tan solo una
lista de reglas condicionales if – then. Lo que se necesita es un
mecanismo para operar a lo largo de la base de conocimiento para
resolver un problema.
A tal mecanismo se le conoce como motor de inferencia,
otra pieza necesaria es el área de trabajo que contenga
las condiciones del problema, esta captura puede realizarse
mediante una lista de verificación, preguntas y respuestas
de opción múltiple o un sistema extremadamente
sofisticado sentado en el idioma natural. Para interactuar con el
sistema experto el usuario captura las condiciones de un problema
en la interfaz del usuario, mismas que las almacena en el
área de trabajo. El motor de inferencia se vale de tales
condiciones para buscar una solución en la base de
conocimiento, la Figura 11, muestra un diagrama de
secuencias de este proceso.
Figura 11. Interacción De Un
Sistema Experto
Fuente: APRENDIENDO UML EN 24
HORAS
1e Joseph Schmuller-2000
9.5.4 MODELADO DE LA BASE DE
CONOCIMIENTO
La representación de UML para las reglas son como
objetos. Contar con uno de los atributos para que sea la parte
if, otra la parte then, agregar otros atributos conforme sea
necesario.
Figura 12. Diseño de la regla
mediante UML
Fuente: APRENDIENDO UML EN 24
HORAS
De Joseph Schrnuller-2000
Para balancear la proliferación respecto a la
necesidad de la simplicidad, primero se crea un sencillo icono
que representa a la regla en la Figura 12, se llena la parte de
if y la parte de then, seguidamente se debe de incorporar cierta
información de identificación para cada regla, se
agrega su nombre en la parte superior: esto logra un par de
cosas:
(1) Convierte a cada regla en única
(2) Muestra a donde ir en el catalogo de reglas para
obtener una descripción y explicación completa de
la regla.
Si una regla es parte de un subgrupo de reglas, se puede
tratar al subconjunto como un paquete. Luego agregar el paquete
de información al identificador de la forma usual propia
del UML, hacer que el nombre del paquete anteceda a un par de dos
puntos (::), que antecedan al identificador. Concluido el paso de
análisis de requisitos, se pasa al siguiente paso el
"Diseño del Sistema Experto".
Las investigaciones
que se emplearán en el desarrollo del trabajo de grado
son:
INVESTIGACIÓN DESCRIPTIVA
La investigación descriptiva busca especificar
propiedades, características y rasgos importantes de
cualquier fenómeno que se analice. [HERNÁNDEZ,
2002]
Se tendrá una investigación descriptiva
debido a que se busca especificar los requerimientos de software,
recolectando información que ayude a esta
investigación, para poder elaborar
la documentación de requerimientos de software
acorde a los problemas que presenten en la actualidad los
desarrolladores de software.
10.1 MÉTODOS
"El método es
una especie de brújula en
la que no se produce automáticamente el saber, pero que
evita perdernos en el caos aparente de los fenómenos,
aunque solo sea porque indica como no plantear los problemas y
como no sucumbir en el embrujo de prejuicios predilectos". [SAM,
1996]
El método es el camino para llegar a un
fin. En consecuencia, los métodos de
investigación serán los procedimientos
que se apliquen para lograr los objetivos que los investigadores
se proponen.
Los distintos métodos que se utilizarán en
el desarrollo del trabajo de grado son:
10.1.1 MÉTODO CIENTÍFICO
John Dewey (1910) en su obra "How We Think" establece
cinco pasos en el pensamiento
reflexivo (que ahora se asocia y describe como Metodología de la investigación,
Roberto Hernández Sampieri, Carlos Fernández
Collado, Pilar Baptista Lucio, 63 pp., Mc Graw Hill, Colombia 1996, ):
[LAB, 2001]
- Percepción de una dificultad
- Identificación y definición de la
dificultad - Soluciones propuestas para el problema: la hipótesis.
- Deducción de las consecuencias de las
soluciones
propuestas. - Verificación de las hipótesis
mediante la acción
A pesar de que el método
científico se lo dividió en cinco pasos se
tiene un modelo del mismo, (ver figura 13) en el cual se puede
observar más detalladamente todos los pasos.
El problema: Los problemas no se inventan,
entonces ¿Cómo surgen? Se requiere un observador
perspicaz que detecte una incongruencia entre lo observado con
las teorías
y modelos vigentes. [LAB, 2001]
En el presente trabajo de grado se ha detectó el
problema general como también los problemas secundarios,
los cuales se los ha expuesto en el Planteamiento del
problema.
La hipótesis: "Es una tentativa de
explicación o conjetura verosímil, que debe ser
sometida a prueba por los hechos que pretende
explicar".
Figura 13. Modelo Geométrico del
Método Científico
Fuente: http://www.umce.cl/biblioteca/mie_modulo4.pdf
Las hipótesis pueden ser contrarias al sentido
común, o bien estar de acuerdo con él, así
como darse el caso de que sea correcta o incorrecta. De todos
modos siempre debe conducir a pruebas empíricas. [LAB,
2001]
En el trabajo de
grado se ha llegado a determinar la hipótesis que se
pretende demostrar.
Las predicciones: Corresponden a hechos
particulares que se deducen como consecuencias de cierta
hipótesis. [LAB, 2001]
Las predicciones, estará referido a en que medida
el sistema experto contribuirá al desarrollador de
software en la documentación de los requerimientos de
software reduciendo el tiempo y
costos
innecesarios, cooperará a la confirmación o
negación de la hipótesis planteada.
El test o
prueba: Es el procedimiento de
observación o experimento necesario para
comprobar la predicción respectiva. [LAB, 2001]
Las pruebas que se realizarán para comprobar las
predicciones se las hará en el desarrollo de prototipos
que serán probados por los desarrolladores de software
disponibles, como también de los estudiantes de la
Escuela
Militar de Ingeniería.
Las evidencias: Corresponden a los resultados
tangibles que quedan del test o prueba. [LAB, 2001]
Al realizar las pruebas se podrá tener
información que evidencien las fortalezas y debilidades,
la cual será utilizada para poder mejorar el sistema
experto.
La nueva teoría: Cuando finalmente se acepta la
validez de una hipótesis, ésta constituye la base
de una nueva teoría que puede considerar nuevos modelos.
[LAB, 2001]
En el caso de que la hipótesis sea válida
se podrá desarrollar una nueva teoría respecto a
como realizar la documentación de requerimientos de
software, lo cual apoyará en el surgimiento de diversas
aplicaciones, como sistemas expertos que ayuden al
desarrollador de software en las diversas etapas de la
construcción de software.
Nuevas observaciones: La aplicación de la
nueva teoría a la realidad permite dar interpretaciones
más ajustadas a los hechos que se van observando. Si
algún observador agudo encuentra que ciertos hechos ya no
encajan con la teoría o el modelo explicatorio y su
interpretación no funciona para ellos,
entonces tenemos una nueva situación problemática
que habría que resolver. [LAB, 2001]
Al contar con trabajos de grado realizados anteriormente
afines al objeto bajo estudio será de gran aporte para
poder obtener información, la cual se filtrará
obteniendo partes de estos trabajos que podrán ser
relevantes para el presente trabajo.
Las aplicaciones prácticas:
Invariablemente después de algún tiempo, van
surgiendo productos y procesos tecnológicos a partir de
los nuevos descubrimientos científicos. [LAB,
2001]
Al concluir este trabajo servirá como base para
la investigación de nuevas aplicaciones como sistemas
expertos que ayuden al desarrollador de software en las diversas
etapas de la construcción de software.
Es el razonamiento que, partiendo de casos particulares,
se eleva a conocimientos generales. Este método permite la
formación de hipótesis, investigación de
leyes
científicas, y las demostraciones. [LOP, 1984]
Este método se lo utilizó para la
formación de la hipótesis.
10.1.3 MÉTODO HIPOTÉTICO
Un investigador propone una hipótesis como
consecuencia del conjunto de datos empíricos, lo cual
arriba a la hipótesis mediante procedimientos inductivos,
y posteriormente realiza experimentos para
poder rechazar o aceptar la hipótesis. [LOP,
1984]
Se usará para poder llevar a cabo las pruebas del
sistema experto que colaborará a rechazar o aceptar la
hipótesis.
10.1.3 MÉTODO DE LA
ABSTRACCIÓN
Es un proceso importantísimo para la
comprensión del objeto, mediante ella se destaca la
propiedad y
relación de las cosas y fenómenos. No se
limita a destacar y aislar alguna propiedad y
relación del objeto asequible a los sentidos,
sino que trata de descubrir el nexo esencial oculto e inasequible
al conocimiento empírico. [OCH, 2002]
Mediante este método se pretende analizar y
comprender el objeto bajo estudio para poder establecer los
componentes y sus relaciones de esté.
10.2 TÉCNICAS
"La técnica es una forma particular
para realizar o aplicar un método, normalmente una
técnica está referida a los procedimientos que son
empleados para la acumulación y manipulación de los
datos". [YAÑ, 2001]
"Podría definirse como el conjunto
de procedimientos y recursos de que
se vale la ciencia
para conseguir su fin. Sin embargo, el nivel del método o
de los métodos no tienen nada en común con el de
las técnicas, entendiéndose, las técnicas
como procedimientos operativos rigurosos. Bien definidos,
transmisibles y susceptibles de ser aplicados repetidas veces en
las mismas condiciones". [GRA, 1996]
10.2.1 ENTREVISTAS Y
CUESTIONARIOS
Las entrevistas y cuestionarios se emplearán para
reunir información proveniente de los desarrolladores de
software, información que se obtendrá conversando
con el encuestado.
Para la realización de las entrevistas se debe
coordinar previamente la fecha y hora, y realizar un plan de agenda,
en el cual se hace un punteo del objetivo de la entrevista.
Por ejemplo, en la primer entrevista
estableceremos un plan de comunicación, en el cual se
intercambiarán los teléfonos, celulares,
direcciones de e-mail y horarios de contacto.
Para realizar las entrevistas, se llevará
preparado un cuestionario.
En términos generales, un cuestionario consiste en un
conjunto de preguntas presentadas a una persona para su
respuesta. La forma de la pregunta puede influir en las
respuestas, por lo que hay que planearlas cuidadosamente. [KOM,
1993]
Las preguntas suelen distinguirse en dos
categorías: abiertas y cerradas. Las preguntas abiertas
permiten que los encuestados respondan con su propia
terminología. Generalmente estas son más
reveladoras, ya que los interrogados no están limitados en
sus respuestas. [KOM, 1993]
10.2.2 ENCUESTAS
Son las que están basadas en muestrarios bien
elaborados con el objeto de permitirnos llegar a conclusiones y
sus fundamentaciones. [YAÑ, 2001]
Se utilizó la encuesta para
poder recopilar datos específicos de los desarrolladores
de software, que ayudó a identificar los problemas
existentes que estan descritos en la sección del planteamiento del
problema.
10.2.3 BRAINSTORMING (TORMENTA DE
IDEAS)
Este es un modelo que se usará, en el desarrollo
del sistema experto, para generar ideas. La intención de
su aplicación es la de generar la máxima cantidad
posible de ideas para el software.
No hay que detenerse en pensar si la idea es o no del
todo utilizable. La intención de este ejercicio es
generar, en una primera instancia, muchas ideas. Luego, se
irán eliminando en base a distintos criterios como, por
ejemplo, "caro", "impracticable", "imposible", etc. [KOM,
1993]
Las reglas básicas a seguir son:
- Los participantes deben pertenecer a distintas
disciplinas y, preferentemente, deben tener mucha
experiencia. Esto trae aparejado la obtención de una
cantidad mayor de ideas creativas. - Conviene suspender el juicio crítico y se
debe permitir la evolución de cada una de las ideas,
porque sino se crea un ambiente hostil que no alienta la
generación de ideas. - Por más locas o salvajes que parezcan
algunas ideas, no se las debe descartar, porque luego de
maduradas probablemente se tornen sumamente
útil. - A veces ocurre que una idea resulta en otra idea, y
otras veces podemos relacionar varias ideas para generar una
nueva. - Escribir las ideas sin censura. [KOM,
1993]
11. TEMARIO TENTATIVO (ÍNDICE)
CARATULA
DEDICATORIA
AGRADECIMIENTOS
INDICE
RESUMEN
CAPITULO 1: GENERALIDADES
- INTRODUCCION
- ANTECEDENTES
- PLANTEAMIENTO DEL PROBLEMA
- OBJETIVOS
- HIPOTESIS
- JUSTIFICACION
- ALCANCES Y APORTES
CAPITULO 2: MARCO TEÓRICO Y
METODOLOGICO
2.1 MARCOS DE PROBLEMA
2.2 INGENIERÍA DE REQUERIMIENTOS
2.3 SISTEMAS EXPERTOS
2.4 METODOLOGIA DE WEISS Y KULIKOWSKI
2.5 LENGUAJE DE MODELADO UNIFICADO UML
CAPITULO 3: MARCO PRÁCTICO
3.1 RECOLECCION DE
DATOS PARA EL DESARROLLO DEL PROYECTO
3.2 DISEÑO DEL SISTEMA EXPERTO
3.3 CONSTRUCCION DEL PROTOTIPO
3.4 VALIDACION Y PRUEBA
3.5 PRUEBA DE HIPOTESIS
CAPITULO 4: ESTUDIO DE COSTO –
BENEFICIO
4.1. DETERMINACIÓN DE COSTOS
4.2. ESTIMACIÓN DE BENEFICIOS
4.3. ANÁLISIS COSTO BENEFICIO
CAPITULO 5: CONCLUSIONES Y
RECOMENDACIONES
5.1 CONCLUSIONES
5.2 RECOMENDACIONES
BIBLIOGRAFIA
GLOSARIO
ANEXOS
12. COSTO DE
REALIZACION DEL TRABAJO DE GRADO
Para llevar el Trabajo de Grado se estiman los
siguientes costos:
Tabla 3. Costos del Trabajo de
Grado
Nombre | Cantidad | Precio |
Papel | 2000 hojas tamaño | 120 |
Libros | 3 libros | 450 |
Documentos de Internet | 100 horas | 200 |
Tinta | 4 cartuchos | 80 |
Fotocopias | 1000 fotocopias | 100 |
Material de escritorio | – | 200 |
Hardware | – | – |
Software | – | – |
Total 1090 |
Fuente: Elaboración
Propia
Tabla 4. Cronograma de
Actividades.
Fuente: Elaboración
Propia.
REQUERIMIENTO: característica del sistema que
es una condición para su aceptación.
INGENIERÍA DE SISTEMAS: Es la disciplina a
la que se refiere a la planeación, diseño, evolución
y construcción científica de sistemas hombre maquina
y cuya característica son de ser complejos y
conflictivos.
ANALISIS DE SISTEMAS: El análisis de
sistemas esta orientado al estudio de o de los sistemas de
una organización identificando aspectos de conflicto, a
todo ello lo denominamos análisis, posteriormente
realizaremos
INGENIERÍA DE SOFTWARE: Es la disciplina
encargada del estudio del producto del software, tal estudio
estas referido a la proporción de nuevos paradigmas
técnicas y herramientas
inmersas en la elaboración. Debemos mencionar que la
ingeniería del software hace uso de otras disciplinas como
la
administración, estadística y probabilidad, las
matemáticas, la psicología,
etc
INGENIERÍA DE REQUERIMIENTOS: conjunto de
actividades en las cuales, utilizando técnicas y
herramientas, se analiza un problema y se concluye con la
especificación de una solución
SISTEMA EXPERTO: Es un software que imita el
comportamiento de un experto humano en la solución de un
problema. Pueden almacenar conocimientos de expertos para un
campo determinado y solucionar un problema mediante
deducción lógica de conclusiones
PROTOTIPO: Es un modelo a escala, pero no
tan funcional para que equivalga a un producto final, ya que no
lleva a cabo la totalidad de las funciones necesarias del sistema
final. Proporcionando una retroalimentación temprana por parte de los
usuarios acerca del Sistema
MARCO DE PROBLEMA: Los marcos de problema caracterizan
clases de problema que comúnmente ocurren como
subproblemas de otros problemas más grandes y
reales
[JAC, 1995] Jackson, Michael, Requerimientos de Software
y Su Especificacion, Addison- Wesley, ACM Press, 1995.
[BRO, 1995] Frederick P. Brooks, Jr., The Mythical
Man-Month, Addison-Wesley, 1995.
[CRI y KANG, 1992] M. G. Christel y K. C. Kang. Los
Problemas en los Requerimientos y Elicitación. El Informe
técnico CMU/SEI-92-TR-12, Software que Diseña el
Instituto, Carnegie Mellon University, 1992. Disponible en
http://www.sei.cmu.edu.
[HSI, 1993] P. Hsia, A. Davis, y D. Kung. Los estados
Informan: La Ingeniería de requerimientos. El Software de
IEEE, 10(6), Noviembre 1993.
[IEEE, 1993] [IEEE 1993] IEEE. IEEE La Práctica
recomendada para las Especificaciones de Requerimientos de
Software. IEEE/ANSI Standard 830–1993, El instituto de
Eléctrico e Ingenieros de la Electrónica, 1993.
[POH, 1997] K. Pohl. La Ingeniería de
requerimientos: Una Apreciación global. La enciclopedia de
Informática y Tecnología, 36, 1997.
Disponible en
http://sunsite.informatik.rwth-aachen.de/CREWS/reports96.htm
.
[POH 1994] K. Pohl. Las Tres Dimensiones de
Ingeniería de Requerimientos: Un Armazón y su
Aplicación. Los Sistemas de
información, 3(19), Junio 1994.
[BOE, 1994] B. W. Boehm, P. Bose, E. Horowitz, y M.-J.
Lee. Software Requirements as Negotiated Win Conditions. En
Los procedimientos de la Primera Conferencia
Internacional en la Ingeniería de Requerimientos,
1994. Disponible en
http://sunset.usc.edu/TechRpts/Papers/NGPMRequirements93.
[DAV, 1993] A. M. Davis. Remontando: Una Necesidad
Simple Descuidó. IEEE Software, 12(5), Septiembre
1995.
[BRA, 1990] J. W. Brackett. Los Requerimientos del
software. El Módulo del plan de estudios
SEI-CENTÍMETRO-19-1.2, Software que Diseña el
Instituto, Carnegie Mellon University, 1990. Disponible en
http://www.sei.cmu.edu.
[DOD, 1994] DOD. La Norma Militar 498: El Desarrollo
del Software y Documentación. Departamento de Defensa de
los Estados Unidos de
América, 1994. Disponible en
http://www-library.itsi.disa/mil/mil std/498 win3.exe.
[CAT, 1999] Sistemas Expertos y Modelos de Redes
Probabilísticas Enrique Castillo, José Manuel
Gutiérrez, y Ah S. Hadi.
[GOG, 1994] J. A. Goguen y C. Linde. Las técnicas
para los Requerimientos Elicitación. Los Procedimientos
del Primer Simposio
Internacional en el Diseño de Requerimientos 1993.
También aparece en [Thayer y Dorfman 1997]. Disponible en
http://www.cse.ucsd.edu/˜goguen.
[MAP, 1995] MAP. Metodología de Planificación y Desarrollo de Sistemas de
Información. MÉTRICA Versión 2.1.
Tecnos/Ministerio para las Administraciones Públicas,
1995.
[BAS, 1998] L. Bass, P. Clements, y R. Kazman.
Nonfunctional Requirements Is a Dysfunctional Term. En
Software Architecture in Practice, Addison–Wesley,
1998.
[ROM, 1990] H. D. Rombach. Software Specifications: A
Framework. Curriculum
Module SEI–CM–11–2.1, Software Engineering
Institute, Carnegie Mellon University, 1990. No está
disponible en http://www.sei.cmu.edu, aunque aparece en [Dorfman
y Thayer 1990].
[MAZ, 1994] C. Mazza, J. Fairclough, B. Melton, D. de
Pablo, A. Scheffer, y R. Stevens. "Standards de Ingeniería
de Software". Prentice–Hall, 1994. Disponible en
http://dxsting.cern.ch/sting/ESA.txt.
[LAB, 2001] Labarca. "METODOLOGÍA DE LA
INVESTIGACIÓN". 2001
[YAÑ, 2001] Yañez Romero Fernando,
"APUNTES DE METODOLOGÍA DE LA INVESTIGACIÓN",
2001
[SAM, 1996] Roberto Hernández Sampieri, Carlos
Fernández Collado , "METODOLOGÍA DE LA
INVESTIGACIÓN", Mc Graw Hill, Colombia 1996.
[GRAW, 1996] Grawitz, Madeleine. "METODOS Y TECNICA DE LAS
CIENCIAS
SOCIELES" Ed. Edita Mexicana S.A., México,
1996. www.entrebits.com
[MED, 2004] Medina Miranda Freddy, "SISTEMAS EXPERTOS Y
REDES
NEURONALES" Apuntes de clases, 2004
[CAS, 2002] Castro Marcel (2002). "SISTEMAS EXPERTOS".
Consultado en
http://strix.ciens.ucv.ve/~iartific/Material/PP_Sistemas_Expertos.pdf
[LOP, 1984] López Cano José Luis,
"MÉTODOS E HIPÓTESIS CIENTÍFICAS",
México, 1984
[KOM, 1993] Komer, P., "DIRECCION DE LA MERCADOTENIA".
Séptima Edición. España.
Prentice Hall.
[WEI, 1984] Weiss y Kulikowski, "SISTEMAS EXPERTOS",
Prentice–Hall, 1984.
[GAO, 1979] Oficina de
Cuentas del
Gobierno
Norteamericano (Government Account Office),
"ESTUDIO GAO", 1979.
[TSG, 1995] Grupo Standish, "ESTUDIO CHAOS",
1995.
[ESP, 1996] European Software Process Improvement
Training Initiative, "ESTUDIO ESPITI", 1996.
[BOOCH, 1996] Benjamin Cummings. "Análisis y
Diseño Orientado a Objetos", 1996.
[RUM, 1996] Rumbaugh James, "Modelado y Diseño
Orientado a Objetos", 1996
ARBOL DE PROBLEMAS
Figura 14. Árbol de
Problemas.
Fuente: Elaboración
Propia.
ANEXO B
ARBOL DE OBJETIVOS
Figura 15. Árbol de
Objetivos.
Fuente: Elaboración
Propia.
Autor
Nelson Huanca Pinto
La Paz Bolivia
Página anterior | Volver al principio del trabajo | Página siguiente |